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Abstract 
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We  show  how  predicate  logic  can  be  used  to  derive 
programs  from  axiomatic  specifications.  We  also 
chow  how  its  proof  theory  can  be  used  to  analyse, 
and  re-char acterize,  the  computations  of  a program. 

1,  Programs  sb  computationally  useful  theorems 

We  start  with  a set  of  axioms  that  give  an  intuit- 
ively correct  characterization  of  some  input-output 
relation  we  wish  to  compute.  Under  the  procedural 
interpretation  of  logic  [5.6]  these  axioms  can  be 
used  to  'compute'  the  relation.  So  we  'symbolically 
execute'  the  axioms,  qua  program,  for  various  forms 
of  input.  From  each  symbolic  execution  we  distil  a 
theorem  that  can  double  for  the  axioms  in  the 
business  of  computing  the  relation.  Our  Bet  of 
derived  theorems  is  a logic  program  whose  proced- 
ural use  is  computational. 

Example 

The  following  axioms  are  a specification  for  the 
input-output  relation,  meiu-test,  of  a program  to 
test  if  an  element  u la  a member  of  a list  z.  The 
output  is  to  be  T if  ues,  F if  not.  All  free  var- 
iables (lower  caee)  are  implicitly  universally 
quantified. 

Specification 

MieNIL  (or  ueNIL  +-+  false  ) 
ucv.x  u-v  v ucx 

mem- test  (u,s,t)  •*-*  t-*T  a ues  v t-F  a Mies 

In  several  respects  this  axiomatisation  is  incom- 
plete. We  should  really  axiomatise  the  equality 
relation  for  lists,  and  list  elements,  and  express 
the  finiteness  condition  for  lists  by  an  induction 
schema  [ 3] . However  the  absence  of  explicit  equal- 
ity axioms  is  an  implicit  assumption  that  things 
are  equal  only  if  tney  are  identically  named,  which 
is  what  we  intend,  and  wa  shall  not  need  the  induc- 
tion schema  for  the  program  synthesis. 

Synthesis 

We  'evaluate1  the  definition  of  mem-test  for  the 
cases  z-NIL  and  z-v.x  . 

z-NIL 

mem-test (u, NIL, t)  *■>  ►-T  t ueNIL  v t«F  » tuENTL 

Using  the  axiom  ucWlL  false  the  'call'  ueNIL 
evaluates  to  false  , giving 

mem-test  (u,NIL,  t)  <-*■  t«T  a false  v t»F  t vfaisj 

The  definiens  now  reduces  to  t«F  using  only  logical 
evaluation  rules.  In  effect  we  have  proved 

item-test (u,NIL,F)  (1) 

Z-V.X 

mem-test  (u,  v.x,t)  «-*  t«T  a ucv.x  v t-F  t Mitv.x 
This  time  we  evaluate  the  'call'  ucv.x  by  substit- 


uting the  equivalent  expression  u-v  v ucx  . 

mem-test  (u,v.x,t)  *-*• 

t- T a (u-v  v ucx)  v t-F  a Mu-V  v ucx) 

We  now  bring  the  components  of  the  substituted 
expression  to  the  surface  by  distributing  connect- 
ives. We  do  this  in  order  to  throw  together  form- 
ulae such  as  PA  P that  can  be  logically  evaluated. 
But,  more  Importantly,  we  'multiply  out'  in  the 
hope  of  eventually  'factoring  out'  an  expression 
that  is  just  another  Instance  of  the  mem-test  def- 
iniens. If  we  can  do  this  we  have  found  a recur- 
sive use  of  the  mem-test  definition  from  which  we 
can  infer  a recursive  theorem.  Distributing  gives 

mem-test(u,v.x,t)  «-» 

t«T  a u-v  v|fT  a ucx  y t-F  a u><v  a Miexj 

The  boxed  disjunction  very  nearly  matches  the  mem- 
test  definiens.  The  'difference'  is  the  extra 
condition  u»*v  that  appears  in  its  right  disjunct. 

We  could  factor  this  out  if  it  also  appeared  in 
the  left  disjunct.  So  we  introduce  it! 

mem- test (u, v. x, t)  ♦ 

t-T  a u-v  v t-r  a u»<v  a ucx  v t-F  a u»*v  a mux 

But  note  that  the  has  been  down-graded  to 

Introducing  ufv  destroys  the  equivalence.  However, 
since  t*T  a ufv  a ucx  implies  t-T  a ucx,  we  still 
have  the  lf-half  of  the  iff.  We  now  factor  out  uj*v. 

mem-test (u,v.x,t)  ♦ 

t-r  * u-v  v upv  a (t-T  a ucx  v t»F  a Miex) 

Substituting  mem-test(u,x,t)  for  its  definiens  gives 

mem-test  (u,v.x,t)  * c-T  a u-v  v u»*v  a mem-test  (u,x,t) 

which  we  expand  as  the  pair  of  theorems! 

mem-test (u,u.x,T)  (2) 

mem- test (u, v.x,t)  ♦ ui*v  a mem-test(u,x,t)  (3) 

Theorems  (1) , (2) , and  (3)  are  the  statements  of 
our  derived  program.  With  minor  syntactic  changes, 
they  are  in  fact  a PROLOG  program  [lo],  PROLOG 
being  essentially  a 'top-down'  resolution  theorem 
prover.  A request  to  refute 

Mnem-test (2, (4. (3. (5. NIL))) ,t) 
is  a call  of  the  program.  It  will  generate  the 
recursive  computation  one  expects.  This  computa- 
tion is  a constructive  proof  tnat  binds  t to  F. 

Correctness 

A logic  program  that  comprises  a set  of  theorems 
about  the  relation  it  is  supposed  to  compute  Is,  in 
the  computational  sense,  (partially)  correct.  (Com- 
puting an  instance  of  the  relation  is  then  proving 
it  is  a correct  instance.)  Thus,  a logic  program  is 
verified  by  checking  that  etch  of  Its  statements 
are  theoremsj  it  is  synthesized  (and  -purified)  by 
finding  each  of  its  statements  as  theorems.  This 
approach  to  verification  and  syntic.slF  is  elabor- 
ated in  [2]. 


The  computations  of  logic  programs  ara  resolution 
proofs.  We  can  characterize  such  proofs  as  paths 
through  an  interconnectivity  graph  [ 8] , tho  unific- 
ations that  appear  on  each  path  being  the  essential 
seeps  of  the  proof  computation.  This  conceptualiz- 
ation of  what  constitutes  a proof  gives  us  a tool 
for  analysing,  and  reformulating,  a logic  program. 


Example 


The  logic  program 

Fact  (0,1) 

Fact  (n+1 , (n+1)  Xy)  * Fact(n,y) 
ia  used  to  compute  the  factorial  function  by  asking 
for  a refutation  of  a conjecture  of  the  fora 
''-Facttu.v)  where  u is  some  numeral  input.  Below  is 


t 


I 


an  interconnectivity  graph  for  the  general  theorem 
proving  task  in  which  the  conditional  statement  has 
been  expressed  in  clausal  form.  Unifiable  comple- 
mentary literals  are  connected  with  an  edge  labelled 
by  the  unifying  substitution. 


~-^Fact  (0,1) 

^ b:  [0/n,  1/y]^^  c^n+l/n’ , (n+1)  X y/y’  ] 
<VFact(n,y)  v Fact  (n+1,  (n+1)  X y) 
a:  [0/u,  l/v]s\  [n+l/u,  (n+1)  X y/v] 


''-Fact  (u,v) 


A proof  of  Facttu.v)  is  given  by  any  path  through 
the  graph  that  connects  ^Fact(u,v)  with  Fact (0,1). 

In  thiB  case  the  set  of  all  possible  paths  can  be 
succinctly  described  by  the  regular,  expression 
a | bc+d  . In  effect,  this  is  an  iterative  charact- 
erization of  the  set  of  compositions  of  unifications 
that  constitute  a proof.  Taking  into  account  the 
intended  use  of  the  logic  program,  i.e.  that  u is  to 
be  input  and  v output,  it  is  a compact  notation  for 
the  iterative  program: 

1)  a:  if  u-0  then  v*-l  , 

2)  )>:  initialise  u'-*0»  v’*-l 

c*:  repeat  (zero  or  more  times) 
u'+u'+li 
v*-*-u'  X v' 

d:  terminate  above  loop  when  u'“u 
v+v' 


General  method 

The  above  example  was  simple  enough  for  us  to  read 
off  directly  from  the  graph  a regular  expression. 

For  more  complex  examples  we  may  first  need  to  char- 
acterize the  set  of  proofs  by  a context  free  attri- 
bute grammar.  This  we  can  always  do  [9].  The 
productions  of  such  a grammar  reflect  the  ground 
structure  of  the  problem,  taking  into  account  unif- 
iable pairw  of  literals,  but  ignoring  the  necessary 
substitutions.  The  attributes  carry  the  substitu- 
tion information.  Temporarily  Ignoring  the  attri- 
butes we  try  to  re-express  thu  language  generated 
using  regular  expressions.  To  the  extent  that  we 
are  successful,  we  then  re-introduce  the  substitu- 
tion constraints  as  refinements  of  the  regular 
expressions.  Thus,  in  the  Fact  example,  the  regular 
expression  bc*d  would  be  refined  by  the  constraint 
that  c is  applied  the  number. of  times  to  satisfy 
the  substitution.  The  refined  expression  is  there- 
fore bc<u-1'd  . 


The  attributes  are  consistency  checks  on  the  varl- 
ablesi  a production  can  be  applied  only  if  its 
associated  substitution  constraint  is  consistent 
with  the  substitution  constraint  of  all  previous 
steps  in  the  derivation.  The  refined  regular  exp- 
ression therefore  gives  us  restrictions  on  each  of 
the  variables  that  must  be  satisfied  in  any  proof. 
The  restrictions  on  the  input  variables  determine 
the  domain,  those  on  the  output  variables  the  range. 
For  Fact,  this  analysis  gives  us  0+(+l)*  as  the 
domain,  i.e.  the  natural  numbers,  and,  for  n in  the 
natural  numbers,  nX  ( (n-1)  . .X (2  X 1)  . . ) as  the  range. 

Termination 

If  we  are  able  to  describe  the  set  of  computations 
as  a regular  expression  we  can  use  the  attributes 
to  replace  the  * 1 s with  specific  integer  functions 
of  the  arguments.  If  we  can  do  this  for  every  •, 
that  is  for  every  implicit  iteration,  we  have  proved 
that  every  computation  terminates. 

3.  Final  remarks 

So  far  we  have  only  investigated  the  hand  synthesis 
of  logic  programs.  However  it  is  Intended  to  imple- 
ment an  Interactive  system  which  becomes  more  aut- 
onomous as  the  synthesis  methodology  is  refined  and 
understood.  The  idea  of  synthesing  a recursive 
program  from  the  recursive  use  of  a specification 
first  appeared,  independently,  in  l\]  and  [7], 

Indeed  the  reader  may  have  noticed  the  similarity 
between  our  approach  and  that  of  Darlington  and 
Burstall[l,4] . Like  them  we  use  the  same  formalism 
for  both  specification  and  program  (they  use 
enriched  recursion  equations) , and  like  them  we 
symbolically  execute  the  spec!  cation.  We  have 
derived  much  from  their  work. 

The  proof  theory  analysis  of  computation  13  also 
in  its  beginning  stages.  It  is  in  fact  an  applicat- 
ion of  more  general  work,  currently  in  progress, 
on  the  analysis  of  resolution  proofs.  We  believe 
it  provides  a useful  conceptual iza ion , and  will 
provide  a useful  tool. 
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